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I  INTRODUCTION 


o        This  report  is  part  of  INPUT'S  Telecommunications  Planning  Program.  It  is 
designed  to  help  senior  managers  and  corporate  executives  assess  the 
capabilities  and  limitations  of  IBM's  SNA  networks.  This  report: 

Identifies  SNA-related  business  requiremenl^ 

A 

Analyzes  current  and  anticipated  SNA  technology. 

Evaluates  some  near-competitive  and  compatible  alternatives. 

Recommends  to  senior  management  some  potential  problems  to 
consider  and  the  opportunities  available  with  SNA-related 
architectures. 


A.       PURPOSE  AND  SCOPE 


o        An  understanding  of  Systems  Network  Architecture  (SNA)  is  of  paramount 
importance  to  the  business  community  since  almost  all  major  suppliers  of 
networking  products  and  services  are  basing  their  future  product  lines  and 
network  control  strategies  around  this  architecture  or  its  equivalent. 
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o        SNA  provides  a  unified,  standardized  approach  to  organizing  (and  controlling) 
networks  containing  intelligent  comnnunications  processing  equipnnent. 

o        The  generalized  objective  is  to  develop  an  efficient  and  reliable  architectural 
frannework  in  which  users  can  view  complex  connmunications-based  connputer 
systems  without  concern  for  the  physical  details  of  how  a  specific  network 
function  is  organized. 

o        Since  seventy  percent  of  all  installed  architecture  is  SNA  or  SNA-related,  a 
clear  understanding  of  the  capabilities  and  limitations  of  SNA  is  necessary,  as 
well  as  an  understanding  of  its  associated  protocols,  such  as  X.2I  and  X.25. 
Similarly,  the  users  should  be  aware  of  packet  switching  and  its  capabilities, 
as  well  as  understanding  the  OSI  reference  mode.  Only  in  this  way  can  the 
user  fully  exploit  the  opportunities  presented  by  these  protocols  and 
associated  architectures. 


B.       REPORT  ORGANIZATION 


This  report  is  organized  as  follows: 
Chapter  I  is  an  introduction. 


Chapter  II  is  an  executive  summary^formatted  as  a  presentation  for 
group  discussions,  and  emphasizi^  the  key  points  within  the  report. 

Chapter  III  is  a  technological  assessment  of  the  architecture  and 
includes  an  analysis  of  packet  switching,  OSI  models,  and  of  the  various 
ancillary  protocols  associated  with  SNA. 

Chapter  IV  contains  the  conclusions  and  INPUT'S  recommendations  for 
effective  network  architecture  planning. 
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The  Appendix  contains  the  questionnaire  used  to  conduct  the 
interviews^«jeiilifyiiig  wl'ut  is  happending  in  Ihe  Field  of  iielwuik 
^onf  igurqt4ens-Qod  control. — 


C.  METHODOLOGY 


The  infornnation  contained  in  this  report  was  derived  from  the  following 
source^^ 

Interviews  with  senior  telecommunications  planning,  vendors,  and 
information  systems  managers  and  executives.  Copiol^  the. 
questionnaire.areeorrrat«ed  in  the  Appendix. 

In-depth  interviews  with  senior  planning  managers  and  executives. 
Copies  of  the  questionnaire  are  contained  in  the  Appendix. 


INPUT'S  studies  on  telecommunications. 

Open  literature  surveys. 

o         INPUT  has  taken  the  best  practices  and  proposa Island  subjected  them  to 
further  analysi^te-servo  Qg-u  bei3ia-4of-4his~repQt:^__^  ^nJ^ 

D.       OTHER  RELATED  INPUT  REPORTS 

o         Interested  readers  are  referred  to  the  following  INPUT  reports: 

Telecommunications  Planning  Methodologies,  October  1 984. 
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Defines  and  describes  telecommunications  planning  techniques 
and  processes,  using  the  case  example  approach,  and  fj!pw« 
identifies  critical  telecommunications  planning  issues. 

Telecommunications  Annual  Planning  Report,  November  1984. 

An  in-depth  survey  and  analysis  of  the  current  state  of  the 
telecommunications  industry,  with  emphasis  on  an  assessment  of 
the  technology. 


Telecommunications  Interfaces  for  the  mid- 1  ^SO's,  December  1984 


An  in-depth  evaluation  of  telecommunications  interfaces  and 
their  ancillary  hierarchies,  including  reference  models, 
protocols,  and  architectures. 

Annual  Information  Systems  Planning  Report,  July  1984. 

Evaluates  information  systems  trends  and  graphically  plots 
critical  IS  management  issues. 

Impact  of  Communications  Developments  on  Information  Services 
Vendors,  December  1 98 1 . 

Analyzes  changing  communications  technology  and  services  as 
related  to  information  services  activities. 


Effective  Corporate  Planning  in  the  Computer  Services  Industry, 
December  1980. 

Examines  the  level  and  extent  of  corporate,  market,  industry, 
and  product  planning  within  the  Computer  Services  Industry. 
Emphasis  is  on  corporate  planning  efforts. 
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User  Communication  Networks  and  Needs,  November  1 980. 

0 

Identi^es  and  evaluates  changes  in  user  needs  within  the 
A 

communications  field;  with  particular  emphasis  on  network 
problems  and  solutions. 

Digest  of  Trends  in  the  United  States  Telecommunications  Industry, 
1980. 

A  special  study  for  a  foreign  government  agency,  the  report 
discusses  the  trust  and  direction  of  telecommunications  effort  in 
the  U.S. 
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EXECUTIVE  SUMMARY 


This  executive  summary  is  designed  in  a  presentation  format  in  order  to: 


Help  the  busy  readet/quickly  review  key  research  findings. 


Provide  an  executive  presentation  and  script  that  facilitates~grODp 
communicaticms. 


The  key  points  eff  the  entire  report  are  summarized  in  Exhibits  11- 1  through  II- 
8.  On  the  lefr-hand  page  facing  each  exhibit  is  a  script  explcrining  the 
exhibit's  contents. 
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A.       SYSTEMS  NETWORK  ARCHITECTURE  IS  A  POWERFUL  NETWORK 
VEHICLE 


Since  its  announcement  in  ihe  fall  of  197^,  IBM's  Systems  Network 

Architecture  (SNA)  has  increasingly  become  the  standard  for  dai^^  

communications  networking  in  an  IBM  mainframe  environment/  Today,  SNA  is 
a  powerful  and  flexible  networking  vehicle.  .  l 

IBM  introduced  s«di  p>rodoeW  QS-4i*6^300  series  mainframe,  ee-weH-os-*^ 
more  sophisticated  intelligent  terminal  systems,  to  enhance  and  take 
advantage  of  SNA's  networking  capabilities. 

The  rapidly  increasing  spread  of  IBM's  SNA  and  related  SNA  terminal  usage  is 
creating  a  standard  for  data  communications  network  interfacing.  As  a 
consequence,  non-IBM  equipment  manufacturers  are  being  compelled  to 
incorporate  SNA  capability  in  their  products. 

To  meet  this  growing  user  demand,  many  manufacturers  are  offering  Systems 
Network  Architecture  and  with  Synchronous  Data  Link  Control  (SNA/SDLC) 
capabilities,  using  hardware  and  software  emulation  techniques. 

As  a  result  of  this  rapid  growth  in  SNA-type  equipment  and  network 
configurations,  there  is  a  fast-growing  demand  for  microcomputer  systems 
offering  SNA  emulation. 
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B.       SNA  DEFINES  A  COMPLETE  SPECTRUM  OF  FUNCTIONS  AND 
PROTOCOLS 


At  the  present  time,ynost  3270  systems  employ  the  Binary  Synchronous 
Com  municoti^^ 

^       3270s  employing  BSC  are,  however,  being  replaced  rapidly  by  3270 
terminal  equipment  employing  SNA  protocols. 


IBM  will  continue  to  set  the  standards  for  data  network  and  terminal-to- 
computer  communications  for  the  foreseeable  future. 

IBM  is  migrating  its  customers  to  SNA  in  an  effort  to  recapture  a 
major  nrtefkH^hare  of  the  terminal  market  segment  v?hi«h  was  lost  to 
non-IBM  suppliers  offering  3270  BSC  emulation. 

The  movement  from  BSC  to  SNA  is  required  for  users  to  realize  the 
full  benefits  of  the  SNA  systems  architecture. 


o         Non-IBM  manufacturers  desiring  to  provide  SNA  interface  compatability  are 
required  to  perform  more  complex  and  costly  design  efforts  than  were 
required  in  developing  BSC  compatibilityy'fhis  is  true  since  SN/T deals  with  a 
considerably  broader  range  of  communications  factors  than  does  BSC. 

While  BSC  is  a  protocol  simply  for  transmitting  data,  SNA  defines  a 
complete  spectrum  of  functions  and  protocols  required  to  move 
information  throughout  the  entire  computer-based  network,  not  just 
the  communications  link. 
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C.       SNA  iS  COMPATIBLE  WITH  X.25  PACKET  SWITCHING  NETWORKS  1 


In  1981,  IBM  announced  rte policy  whereby  SNA  products  would  be  deve  A 

so  as  to  communicate  over  X.25  public  packet-switchinq  networks^^mis    i  ^  ?//'"'^ 

—  ■  A  2   ^ 

interface  policy  on  the  part  of  IBM  indicated  IBM's  adherence  to  user  demands 

for  flexible  interconnection  of  various  data  networks  and  equipment  on  a 

worldwide  basis.- 

'     The  SNA-X.25  interfacing  support  from  IBM  paves  the  way  for  the 
^  \  y 

^XV"   computer-communications  explosion  of  the  1980s. 

The  X.25  packet  switching  public  network  standard  was  developed  under  the 
authority  of  CCITT  as  part  of  a  joint  effort  between  Canada,  France,  Japan, 
the  U.K.  and  the  U.S. 

X.25  calls  for  X.2I  as  the  physical  and  electrical  interface  between  the 
customer  terminal  eq||Ll|3ment  and  the  packet  network.  RS-232-C, 


however,  is  authorized  under  X.25  on  an  interim  basis./ Higher-Level 
—       Data  Link  Control  (HDLC)  is  employed  as  the  communications  link 

protocol  under  X.25.  The  packet  serves  as  the  message  format.  Also 
under  X.25  are  set-up  procedures  for  controlling  the  packet ^hich 
consists  of  a  user  data  message  plus  various  control  informatior^f^ 

X.25  offers  the  user  a  functionally  transparent  network  with  elaborate  error- 
checking  capability. 


o  X.25  standardizes  the  interface  between  customer  terminal  equipment  and 

'\  computers  and  public  packet  switching  networks  such  as  Datapac  in  Canada, 

'  ^it^y  Transpac  in  France,  and  PSS  in  the  U.K.  ,  a 

o  In  order  to  provide  X.25  support,  IBM  introduced  two  additional  producist-. i--    '  ^ 

ft(  AX 

.  ^•H  software  package  that  operates  with  IBM's  3705  communications  controller. 
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and  (^ardwQre  prodiJct|Whh*h  converts  the  SNA  link  protocol  (SDLC)  in  and 
out  oftfie  X.25  communications  protocols.  The-sof+w€tf^^5l:ody€4^4s-«Ql4ed-the--^2_ 
Xff^S-fvlelwork  Controi  Program  Packet  Switching  Interf  ace.  _Ihe-bar4war4 
to  as  the  Network  Interfoce- 
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OTHER  COMPANIES  ALSO  MANUFACTURE  SNA/X.25  INTERFACES 


o         In  addition  to  IBM,  other  computer  manufacturers  such  as  DEC  and  NCR  have 
adapted  their  network  architectures  (equivalent  to  SNA)  to  interface  with 
both  X.25  and  SNA.  fr- 

^Many^ther~computer  manufacturers  (such  as  HP  and  Data  General) 
have  also  developed  compatible  software  to  allow  their  computer 
systems  to  handle  both  SNA  and  X.25  networking  requirements. 

o        X.25  Releases  I  and  2  software  allow  for  packet  switching  among  various  host 
systems  and  remote  SNA  cluster  controllers. 

X.25  Release  3  software  provides  host-to-host  computer  packet 
switching. 

Release  2  also  provides  teletype  support. 

Other  companies  supporting  X.25  packet  network  procedures  and 
protocols  to  varying  extents  include: 

DEC'S  Digital  Network  Architecture  (DNA). 

Honeywell's  Distributed  Systems  Architecture  (DSA). 

NCR's  Communications  Network  Architecture  (CNA). 

Sperry  Univac's  Distributed  Communications  Architecture 
(DCA). 

Data  General's  DG/SNA  architecture. 
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■311  'tost  ■. 


Hewlett-Packard's  Distributed  System  Network  (DSN). 
Prime  Computer's  Primenet  architecture. 
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E.       DEC'S  ETHERNET  IS  THE  LARGEST  COMPETITOR 


Digital  Equipment  Corporation  has  announced  a  three-year  program  to  support 
Ethernet  protocols  and  link  DECnet  with  IBM's  Systems  Network  Architecture 
(SNA). 


i 


c5 

Four^^hernet  products  have  been  introduced.  The  first  was  unveiled  in 
I98^DP-I  l-based  DECnet/SNA  Gateway  computer  was  shipped  in 
1983/and  is  still  undergoing  field  testing.  Pricing  should  be  announced 
after  field  testing  is  completed. 


The  first  systems  to  make  use  of  the  Ethernet  products  and  SNA  Gateway 
computer  are  the  VAX  family  and  Unibus^bgsed  PDP-I  L^ubsequent 
applications  will  involve  the  DEC  system  20  and  the  new  Professional  low-end 
microcomputers. 

DEC  has  projected  1 984  for  the  direct  access  to  Ethernet  by  VAXs  and 
Unibus-based  PDP-I  Is. 

DEC  is  also  going  to  be  marketing  a  transceiver,  coaxial  cable,  and  an 
Ethernet  communications  controller  for  Unibus  systems,  as  well  as  software 
support  consisting  of  DECnet-VAX  and  DECnet-RSX  software  packages. 

DEC'S  Ethernet  and  SNA  program  will  be  implemented  via  Phase  IV  of 
DECnet. 


This  new  technology  will  result  in  a  fourfold  increase  in  network  nodes ^ 
from  255  to  over  1 ,000. 
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F.       DECS  GATEWAY  SYSTEM  OFFERS  NON-IBM  COMPATIBILITY 


The  Unibus  communications  controller,  called  DEUNA,  is  priced  at  about 
$3,500  and  became  available  in  mid- 1 983. 


!5 


The  controller  perfoms  data  link  functions  for  its  associated  Ethernet 
node,  proper  channel  access,  and  retransmission  attempts  upon  collision 
detection. 


StajTdardcogxiaj_cable  was  supplied  by  the  company  starting  in  late  1982. 
DECnStTsNXGot^^ 
communicate  with  IBM  computer  systems. 


mmuin 

4 


Systems  connected  to  the  Gateway  via  DECnet  can  access  the 
Gateway's  optional  software  packages/i^hich  include  network 
management,  remote  job  entry  capability,  an  interactive  3270  facility, 
and  an  applications  program  interface. 


The  interactive  3270  module  allows  users  to  interact  with  an  existing  IBM 
application  from  a  VT  100  CRT  terminal,  while  the  applications  program 
interface  allows  users  to  write  application  programs  on  a  DEC  processor  that 
can  communicate  with  IBM  host  application  programs. 
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G.       THE  OPEN  SYSTEMS  INTERCONNECTION  (OSI)  IS  STANDARD 


In  view  of  the  obvious  user  demand  for  broad  compatibility  among  the  various 
major  networking  architectures,  the  International  Standards  Organization 
(ISO)  has  established  a  standard  \3^^ucb  it  refers  to  as  "Open  Systems 
Interconnection"  or  OSI. 


The  OSI  model  consists  of  a  seven-layer  modelpjhree  lower  layers 
representing  thefc)mmunications  functions  of  a  network^a  middle  layer 
to  jnsure  the  integrity  of  information  transfer  between  sending  and 
receiving  computer  systemsf^nd/topVfhreejlayers  relating  to  the  actual 


processing  of  the  information. 

Computer  manufacturers  such  as  Honeywell  and  Univac  have  already 
indicated  that  they  will  support  the  OSI  standard.  It  is  expected  that 
IBM  will  also  eventually  revise  its  SNA  procedures  to  accorrjj^date  OSI. 

o        X.25  (and  X.2 1 )  gjregd)^  comply  with  the  three  lower  levels  of  the  OSI 
^   '^^  standard.  Jtstill  remains  to  be  seen,  however,  how  the  various  equipment 
^     manufacturers  will  handle  the  higher  layers. 

SNA  contains  many  of  the  functions  specified  in  the  higher  levels  of 
OSI  and  could,  therefore,  provide  the  fundamental  basis  for  the 
networking  environment  of  the  1 980s  and  beyond. 
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H,      SNA  PROGRAM  RECOMMENDATIONS 


yc 


Orient^  your  SNA  planning  process  toward  using  programs  directly  concerned 
with  operating  SNA  networks,  such  as  the  following  access  nnethods: 


ii 


'acf/tcam/^ 


ACF/VTAME. 
^ACF/NCP/VS. 


Use  major  programs  and  subsystems  (such  as  transaction  processing  systems 
and  remote  job  entry  programs)  that  help  end  users  move  data,  transactions, 
and  jobs  through  SNA  networks,  such  as: 


CICS/VSx^ 


ACP/TPF. 


Remote  job  entry  (RJE)  programs  for  SNA  networks  and  data  management 
program  components  of  an  MVS  or  DOS/VSE  system  control  program.  Jobs 
can  be  submitted  directly  to  OS  from  remotely  located  input  devices  where 
RJE  subsystems  are  installed: 


OS/VSI  for  RES/JES 
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OS/VSI  with  JES/RJE, 


\ 
i' 

r 


0S/VS2  with  NJE  for  JES2, 


0S/VS2  with  JES3  for  RJE 


DPPX/RJE  worl<stotion  facility 


Yo^Ji  OS/VS  and  DOS/VSE  with  JEP  and  FTP. 


Finally,  IS  management  should  know  that  there  are  three  host-resident 
programs  that  support  programs  in  other  SNA  nodes:  ^ 

^  -   _  

^SSP  for  ACF/NCP/V^A^ 


I 


HCF. 


C 
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Ill       TECHNOLOGY  REVIEW/ANALYSIS 


A,  INTRODUCTION 


o        Systems  Network  Architecture  (SNA)  comprises  the  logical  structure, 
formats,  protocols,  and  operational  sequences  that  govern  information 
transmission  through  an  IBM  data  communications  network,  i.e.,  the  total 
spectrum  of  IBM  networking. 


o        An  important  feature  of  SNA  is  the  transparency  provided  to  the  network  user 
for  most  communications,  which  are  performed  automatically  in  the  SNA 
system. 

Regardless  of  the  size  and  complexity  of  the  network,  SNA  permits  the 
handling  of  many  difficult  communications  problems  and  tasks  with 
little  or  no  operator  intervention. 

The  system  designer  must  take  care,  however,  to  jnsure  that  the 
network  employs  the  full  range  of  SNA's  communications  and 
contingency  management  capabilities. 


o  SNA  also  provides  for  access  to  any  applications  program  from  any  terminal  in 
the  network,  automatic  reconfiguration  of  the  network,  and  automatic  sharing 
of  resources  among  host  processors  in  the  network. 
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o        SNA  fully  supports  the  networking  of  distributed  processors  connected  to  one 
or  more  hosts.  A  broad  variety  of  remote  data  entry  capabilities  is  available 
from  IBM  for  use  with  a  wide  range  of  distributed  systems,  such  as  the  8100 
Information  System,  the  System/38,  the  3790  Communications  System,  the 
Series/ y^nd  others. 

o        SNA  achieves  these  capabilities  through  the  implementation  of  certain  IBM 
hardware  and  software  products,  which  usually  requires  upgrading  of  existing 
IBM  systems.  This  report  outlines  these  hardware  and  software  products  and 
their  intercompatibiiity. 


B.       CHARACTERISTICS  OF  SNA 

o         In  general,  the  implementation  of  four  elements  can  be  said  to  distinguish  an 
SNA  network  from  a  pre-SNA  configuration: 

Programmable  communications  processors. 

Synchronous  Data  Link  Control  (SDLC). 

A  layered  concept  for  each  communications  operation. 

The  implementation  of  certain  SNA  terminals. 

I.       PROGRAMMABLE  COMMUNICATIONS  PROCEDURES 

o        The  implementation  of  an  SNA  network  requires  at  least  one  programmable 
communications  processor,  such  as  the  IBM  3704,  3705^r  3725 
Communications  Controllers.  At  least  one  such  device  must  be  attached 
locally  to  a  host,  to  perform  network  control  functions  externally  to  the 
host.  The  host  is  thereby  relieved  of  routine  communications  processing  and 
permitted  to  concentrate  on  applications  processing. 
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In  larger  SNA  systems,  this  separation  of  function  pernnits  the 
communications  processor  to  shift  its  incoming  data  automatically  to  a 
different,  and  even  remote  host,  in  the  event  that  its  host  fails.  To  a 
limited  extent, ^can  control  network  functions  without 
communicating  with  any  host. 

Additionally,  a  single  front-end  communications  processor  can  serve  up 
to  eight  hosts,  attached  locally  or  remotely. 

In  contrast,  pre-SNA  configurations  have  used  either  a  270X  hard-wired  line 
controller,  or  an  Integrated  Communications  Adapter  for  communications  line 
handling.  (A  370X  or  3725  running  in  emulation  mode  is  really  a  lowermost 
270X,  not  a  fror^t^nd.)  Either  device  requires  that  host  software  and 
processing  power  be  devoted  to  communications  processing,  a  costly  use  of 
host  time  and  memory  resources.  More  importantly  for  SNA,  neither  device 
supports  the  SDLC  line  discipline,  a  key  ingredient  of  SNA  communications. 

IBM  provides  several  different  software  products  whtetvrun  on  the  3704,  3705, 
or  3725.  These  products,  the  choice  of  which  depends  on  the  degree  of 
network  functionality  required,  are  detailed  later  in  this  report. 


SYNCHRONOUS  DATA  LINK  CONTROL  (SDLC) 


SDLC  is  the  IBM  line  protocol  indigenous  to  SNA. 

^  is  a  bit-oriented  discipline  that  can  support  half  or  full-duplex 
transmission,  point-to-point  or  multipoint  lines,  and  leased  or  switched 
facilities. 


Transmission  speed  is  supported  at  up  to  230.4  K  bps. 
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Each  SDLC  transmission  is  composed  of  one  or  more  frames,  each  of  which 
starts  and  ends  with  a  flag  bit  pattern.  Each  frame  contains  an  address  and  a 
control  field.  Each  frame  also  provides  for  error  detection. 

Frames  are  sequenced,  and  up  to  seven  frames  may  be  transmitted 
before  validation  by  the  receiving  device  is  required. 

All  unconfirmed  frames  are  retained  by  the  transmitter  until 
confirmed,  so  that  transmission  can  be  restarted  at  the  frame 
containing  a  detected  transmission  error. 

This  degree  of  data  link  control  primarily  distinguishes  SDLC  from  binary 
synchronous  (BSC)  transmission,  the  pre-SNA,  character-oriented  standard 
protocol  which  IBM  announced  with  the  System/360  in  1964. 

The  control  field  carried  in  the  SDLC  frame  indicates  whether  the  message 
contains  function  management,  data  flow  control,  network  control^r  session 
control  information.  It  also  indicates  whether  the  frame  and  message  are 
supervisory  or  informational,  sequenced  or  non-sequenced. 

All  control  information  is  generated  automatically  and  is  transparent 
to  the  end  user.  SDLC  additionally  permits  low-overhead 
communications  between  SNA  devices  once  a  communications  link,  or 
"session,"  is  established. 

This  type  of  data  transmission  is  termed  the  "record  mode"  of 
operations.  BSC  devices  cannot  communicate  in  this  mode. 

In  any  SDLC  link  between  two  stations,  the  primary  station  controls  all 
communications.  The  secondary  station  can  only  respond. 

Although  BSC  transmission  requires  designation  of  master  and  slave 
stations  for  each  communications  operation,  only  SDLC  permits  a 
single  station  to  be  both  a  primary  and  a  secondary  station. 


_  4  _  (U-SNE-III)  PH  11/13/84 


An  SNA  device  may  communicate  as  o  secondary  station  on  one  line, 
and  as  a  primary  station  on  one  or  more  other  lines. 

ARCHITECTURAL  LAYERING 

SNA  provides  six  layers  of  control  for  every  message  that  passes  across  the 
network. 

A  message  passing  from  one  application  (terminal  or  program)  to 
another  must  pass  through  all  six  layers  at  each  end  of  the 
communications  path.  Some  network  functions,  such  as  routing, 
involve  only  the  lowermost  layers  of  SNA  control. 

A  message  passing  through  an  intermediate  routing  process  between  its 
source  and  destination  passes  through  these  lower  routing  layers  twice 
at  each  routing  node,  once  when  the  routing  process  receives  the 
message,  and  once  as  it  forwards  the  message  toward  its  destination. 

Each  layer  has  specific  responsibilities  in  the  handling  of  a  message. 

Each  layer  communicates  directly  only  with  its  adjacent  layers,  those 
directly  above  and  below  it  in  the  architecture. 

Each  layer  acts  upon  information  only  from  its  parallel  layer  in  the 
process  at  the  other  end  of  the  session.  Thus,  network  designers  can 
change  (update,  revise,  or  improve)  functions  in  any  layer  of  the 
architecture  without  affecting  the  functions  of  other  layers,  as  long  as 
such  changes  are  uniform  in  that  layer  throughout  the  network,  and  do 
not  affect  the  ways  in  whicl?that^yer  passes  information  to  (and 
receives  information  from)  its  adjacent  layers. 
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The  uppermost  two  layers  of  the  SNA  interface,  the  Network  Addressable 
Unit  (NAU)  Services  Manager  and  the  Function  Management  Data  (MFD) 
Services,  together  provide  session  presentation  services  and  application-to- 
application  services. 

Session  presentation  services  include  compression  gRd-Gonipaotio^^f 
data  for  faster  throughput,  and  data  formatting  for  presentation  on 
specific  terminal  screens. 

Application-to-application  services  include  protocol  translation  and  the 
synchronization  of  activities  among  transaction  processing  programs. 

The  NAU  Services  Manager  and  FMD  Services  layers  also  perform 
certain  networl^^ide  services  such  as  configuration  management, 
network  operator  communications,  and  the  initiation  and  termination 
of  sessions  between  applications  in  the  network. 

Below  the  FMD  Services  layer  is  the  Data  Flow  Control  Services  laye^^^AwWetu^ 
sets  the  send/receive  mode  of  the  session,  is  responsible  for  chaining  a'nd 
bracketing  of  messages,  and  provides  some  high-level  error  control. 

SNA  provides  three  alternative  send/receive  modes: 

Full  duplex,  with  concurrent  flow  of  information  in  both 
directions. 


Half-duplex  flip-flop,  in  which  stations  alternate  in  sending 
messages  across  the  session. 

Half-duplex  contention,  in  which  stations  at  either  end  of  the 
session  contend  for  the  use  of  the  communications  link,  with  one 
or  the  other  prevailing  according  to  an  established  convention. 
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Changing  ad  bracketing  epe  ways  of  logically  grouping  units  of  infornnation 
into  larger  groups  for  more  efficient  transmission  and  error  control. 

A  chain  is  such  a  group^ing  sent  in  one  direction  across  a  session. 

A  bracket  is  similar  grouping  established  in  both  directions  across  a 
session  to  jnsure  that  related  units  or  chains  of  information  (such  as  a 
request  and  its  response)  are  handled  properly. 


The  Transmission  Control  Services  layer  paces  the  flow  of  information  across 
a  session,  allowing  a  station  to  send  only  as  much  information  across  the 
session  as  its  partner  can  handle  at  one  time.  'K 

^  (  - — 

*■         Transmission  Control  Services  can  also  provide  encryption  and 

decryption  of  data  on  request  of  the  applications  at  either  end  of  the 
session. 

The  Path  Control  Network  layer  routes  messages  from  their  source  to  their 
destination,  and  controls  the  size  of  the  data  units  actually  transmitted  across 
the  network,  segmenting  long  messages  and  blocking  shorter  messages  for 
efficient  transmission. 

A  sub-function  of  the  Path  Control  layer's  routing  capabilities  is  the 
establishment  of  a  class  of  service  for  each  session  according  to 
parameters  established  by  the  communicating  applications.  A  given 
.  class  of  service  may  provide  higher  transmission  speed,  better  data 
security,  or  a  more  reliable  connection. 

The  Path  Control  layer  provides  an  additional  form  of  message  pacing 
to  handle  peak  loads  across  the  network. 

The  lowest  layer  defined  by  SNA  is  the  Data  Link  layer,  which,  for  data 
transmitted  across  the  network,  formats  messages  into  SDLC  frames,  and 
provides  the  error-control  services  of  SDLC. 
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For  data  transmitted  between  a  channel-attached  device  and  a  host 
processor,  the  Data  Link  layer  user  IBM's  System/370  channel  protocol 
instead  of  SDLC. 


IBM  has  begun  to  implement  specific  protocols  at  the  application  layer, 
"above"  the  seven  layers  defined  by  SNA  for  general  communications  tasks. 

The  first  such  set  of  protocols,  collectively  called  the  Document 
Interchange  Architecture  (DIA),  was  announced  in  1981,  and  attempts 
to  define  a  high-level  standard  for  communications  among  IBM's  office 
automation  systems. 

The  protocols  comprise  a  layered  series  of  application-level 
architectures,  logically  nested  one  within  the  other,  each  specific  to 
one  task  in  the  automated  office. 

DIA  underlines  the  whole  application-level  structure,  and  provides  for 
the  distribution  and  filling  of  documents. 


The  unit  of  information  in  DIA  is  the  Document  Interchange  Unit  (DIU),  a 
logical  envelope  similar  to  the  SDLC  frame,  j*. 

J        All  DIUs  contain  an  identifier,  a  command  field,  a  data  field,  and  one 


ore  more  document  units. 


The  identifier  enables  the  receiving  applica^on  to  reply 
specifically  to  DIUs  that  require  a  response. 


The  command  field  contains  any  DIA  commands,  such  as  orders 
to  distribute  or  file  the  information  contained  in  the  document 


unit. 
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/        The  data  field  contains  data,  such  as  distribution  lists  or  file 


r 


✓  locations,  for  the  commands  in  the  command  field. 


The  document  units  contain  a  document  profile  and  the 
document  contents,  defined  according  to  one  of  several 
Document  Content  Architectures  (DCAs). 


The  DCAs  describe  application-specific  standards  for  such  parameters 
as  column  tabulation,  centering,  and  margin  setting. 

Another  layer  of  the  DIA  scheme  consists  of  Graphic  Codepoint  Definitions 
(CCDs).  These  define  specific  character  sets,  or,  more,  precisely,  the 
assignment  of  specific  characters  to  each  of  the  256  eight-bit  patterns 
available  to  define  a  character  set. 

Each  set  of  256  patterns  is  called  a  codepoint. 

Codepoints  define  only  the  assignment  of  characters;  they  are 
insensitive  to  the  content  of  the  data.  Thus,  the  graphic  expression 
$  1 ,000  In  a  U.S.  codepoint  is  equivalent  to  the  expression  pound  1 ,000 
in  a  British  codepoint,  regardless  of  the  currency  exchange  rate. 

IBM's  office  architectures  currently  apply  only  to  a  small  subset  of  the 
vendor's  product  line.  However,  4ibey  indicate  a  likely  ftttore  direction  for 
-fotore^SNA.  (  . 

Similar  application  architectures,  yet  to  be  developed,  will  bring  the 
SNA  communications  hierarchy  from  the  cable  interface  to  the  user's 
fingertips  in  an  orderly  progression  of  layers. 

End  users  will  need  to  concern  themselves  only  with  the  topmost  layer; 
the  rest  of  the  network  will  be  transparent. 
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C  SNA  TERMINAL  DEVICES 


A  wide  range  of  terminal  products  can  be  employed  in  an  SNA  system, 
although  each  device's  degree  of  programmability  and  protocol  support 
significantly  affects  its  communications  efficiency  within  the  network. 

All  IBM  terminals  whieh  can  be  configured  in  an  SNA  network  are  categorized 
as  either  SNA  or  non-SNA  terminals. 


•i  SNA  terminals  are  generally  those  programmable  devices  wmeh  support 
SDLC  communications  and  the  establishment  and  operation  of  sessions, 
allowing  c 
operation. 


allowing  communica^n  in  the  highly  efficient  record  mode  of 


In  keeping  with  the  layered  concept  of  communications,  each  SNA  terminal 
contains  a  Physical  Unit  (PU),  which  handles  the  device's  interaction  with 
network  communications,  and  one  or  more  Logical  Units  (LU),  which  handle 
communications  with  the  host's  applications  programs,  or  other  logical  units  in 
the  network. 

In  establishing  a  sessio!n_vvith  an  SNA  terminal,  the  PU  is  first 
_______contacted^  After  necessary  communications  administration  with  the 


PU  is  accomplished,  the  addressed  LU  is  then  activated,  and  the  session 
begins. 

The  configuration  of  logical  units  within  SNA  terminals  varies  depending  on 
the  specific  terminal  model. 

With  the  3790  Communications  System,  for  example,  the  379 1 
controller  contains  the  PU  and  an  LU  for  each  attached,  separately^ 
addressable  device  in  the  3790  system. 
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Each  device  with  an  LU  located  in  the  controller  unit  is  capable  of 
initiating  connections  and  disconnections  independently,  and 
comnnunication  with  separate  applications  programs. 

in  an  SNA  network,  all  PUs  and  LUs,  including  any  accessible 
applications  programs  residing  in  the  host,  are  known  as  Network 
Addressable  Units  (NAUs). 

The  discussion  of  PUs,  Lys,  and  NAUs  (all  of  which  are  transparent  to  the 
terminal  operator),  would  be  meaningless  except  for^use  in  contrasting  the 
network's  handling  of  SNA  and  non-SNA  terminals.  BSC  and  asynchronous 
devices  are  non-SNA  terminals,  and  contain  no  network^addressable  units,  but 
many  such  devices  are  accommodated  in  an  SNA  system  nevertheless. 

The  integration  of  these  devices  into  the  network  requires  their  connection  to 
an  SNA  device,  usually  a  3705  or  3725  Communications  Controller. 

For  these  non-SNA  devices,  the  communications  controller  receives 
their  input,  strips  and  retains  the  control  information  fields  of  their 
messages,  and  then  routes  the  messages  accordingly. 

Return  messages  are  likewise  reformatted,  with  the  communications 
controller  sending  the  message  content  with  appropriate  BSC  or  async 
control  characters  inserted. 

BSC  and  async  message  traffic  is  handled  by  the  host  on  an  exception  basis. 

The  host  is  interrupted,  and  must  search  an  interpret  table  before  the 
BSC  or  async  message  can  be  processed. 

The  processing  overhead,  therefore,  for  non-SNA  message  traffic  is 
considerable. 
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D. 


MIGRATION  TO  SNA 


Current  non-SNA  IBM  users  can  gradually  nnigrate  to  an  SNA  system. 

To  understand  the  system  changes  required,  this  section  examines  the 
software  and  hardware  components  required  for  an  IBM  user  to  achieve 
the  minimal  SNA  configuration.  Specifically,  discussed/frehost 
operating  systems, ^telecommunications  access  vneihod[s^^£^S^ 


"communications  controllers  and  their  software  load~^  ^ 


SNA-COMPATIBLE  HOST  OPERATING  SYSTEMS 

Even  the  smallest  SNA  system  requires  an  IBM  System/370  (Model  135  or 
larger),  303X,  308X,  4300,  or  compatible  processor  operating  in  a  virtual 
system  mode. 

The  current  I  y^pported  IBM  operating  systems  in  which  SNA  can  be 
implemented  are:  DOX/VS,  OS/VS 1 ,  0S/VS2  (SVS),  and  0S/VS2  (MVS),  0S/VS2 
(MVS/XA),  DOS/VSE,  and  SSX/VSE  Systems^hich  includ^as  a  subsysterr^at 
least  one  of  these  operating  systern^<jqn  support  SMAi — - 

The  oldest  versions  of  the  operating  system  wWch  supporl^SNA  are: 

DOS/VS,  release  34. 


OS/VS  I,  release  6.0. 
0S/VS2  (SVS),  release  1.7. 
0S/VS2  (MVS)  release  3.0. 
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0S/VS2  (MVS/XA),  release  1 .0. 
DOS/VSE,  release  1.0. 
SSX/VSE,  release  1.0. 


It  can  generally  be  said  that  any  earlier  IBM  release  that  is  still  . 
actively  supported  can  be  upgraded  to  a  more  current  level  which  does 
support  SNA. 


The  user's  choice  of  an  operating  system  will  depend  on  the  particular  system 
configuration  and  applications  required. 

Different  operating  systems,  and  even  different  releases  of  the  same 
operating  system,  offer  widely  varying  special  utility  capabilities  and 
compatibilities.  Thex  likewise  differ  significantly  in  their  support  of 
particular  remote  data  entry  packages  such  as  HASP,  RJE,  RES,  JES^wd-^ 


For  established  or  new  IBM  users,  existing  system  configurations  will 
either  support,  or  can  be  upgraded  to  support  SNA,  as  long  as  one  or 
more  of  the  above  operating  systems  is  in  place. 

SNA  TELECOMMUNICATIONS  ACCESS  METHODS 


Two  IBM  communications  access  methods  support  SNA  and  the  operating 
systems  previously  mentioned.  They  are  the  Telecommunications  Access 
Method  (TCAM)  and  the  Virtual  Telecommunications  Access  Method  (VTAM). 

Within  each  SNA  host  system,  one  of  these  access  methods  is  required. 
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i$  is^key  to 

major  component  of  the  host  operating  system. 


The  communications  access  methods  is^key  to  achieving  SNA  and  is  a 


The  access  method  handles  the  interaction  between  the  host 
application  programs  and  the  local  communications  controller 
(Function  Management  layer).  Its  functions  are  supervised  by  a  System 
Services  Control  Point  (SCP)  within  the  access  method. 

The  SSCP  is  actually  the  "switchboard"  logic  for  the  system  and 
contains  a  matrix  of  defined  communications  parameters  for  each  of 
the  addressable  elements  in  the  network. 

The  SSCP,  like  all  the  Physical  and  Logical  Units  in  the  system,  is  a 
Network  Addressable  Unit,  and  provides  the  necessary  "bind" 
information  for  session  establishment  whenever  a  request  is  received 
from  either  a  terminal  or  an  application. 

Except  for  the  4300  processors,  the  basic  communications  access  method  is 
included  with  the  operating  system  as  System  Control  Programming  (SCP), 
and  is  generated  with  the  system. 


r 


With  the  4300  processor,  however,  IBM  is  providing  unbundled  operating 
software,  and  the  communications  access  method,  as  with  most  other 
operating  utilities,  is  separately  priced. 


TCAM  VERSUS  VTAM 

TCAM  was  IBM's  first  SNA  communications  access  method,  and  is  best  suited 
for  the  IBM  user  migrating  towardj|^an  SNA  system. 

TCAM  provides  more  extensive  support  for  IBM  BSC  and  async  devices 
than  does  VTAM. 
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TCAM  would  similarly  best  serve  a  user  whose  system  is  expected  to 
maintain  a  wide  variety  of  mixed  BSC,  async,  and  SDLC  devices. 

o        VTAM,  conversely,  would  best  serve  the  user  whose  network  uses,  or  plans  to 
use,  predominantly  SNA/SDLC  devices. 

VTAM  provides  for  immediate  access  to  applications  within  the  host, 
whereas  TCAM  uses  message  handling  queues  more  extensively. 

Basic  VTAM  supports  remote  communications  controllers,  whereas 
TCAM  does  not. 

o        As  an  SNA  system  grows,  functional  enhancements  will  need  to  be  added  to 
the  access  method,  whether  TCAM  or  VTAM.  IBM  provides  several  program 
products  for  this  purpose. 


E.       ACF/TCAM  AND  ACF/VTAM 


Advanced  Communications  Function  (ACF)  was  introduced  by  IBM  in  1976, 
with  a  separate  program  product  enhancement  for  both  TCAM  and  VTAM. 


i 


ACF/VTME,  introduced  later  for  the  DOS/VSE  operating  system, 
provides  similar  capabilities  for  4300-Se|^es  systems. 


The  most  significant  capability  of  ACF  is  the  added  ability  to  interconnect 
different  operating  systems  and  different  hosts,  whether  in  the  same  or 
geographically  different  locations. 

An  additional  program  enhancement,  the  Multisystem  Networking 
Facility  (MSNF),  is  required  for  each  access  method  Involved  in  an 
interconnected  network. 
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The  multisystem  capability  provides  any  supported  terminal  within  the 
network  with  full  access  to  any  application  program  in  any  connected  host. 

The  access  method,  in  conjunction  with  the  communications  processor 
(loaded  with  a  similar  ACF  program),  provides  network  transparency  to 
both  the  application  and  the  terminal  involved.  The  terminal  operator 
need  not  even  know  which  host  controls  the  application  he  or  she  is 
using. 

Without  the  MSNF,  terminal  and  line  switching  from  one  host  system  to 
another  could  only  be  achieved  through  host  system  operator  commands 
or  through  user-programmed  procedures. 

ACF  additionally  provides  IBM  users  with  a  switched4ine  capability  for 
remote  SNA  devices,  support  for  remote  communications  controllers  for 
TCAM  in  ACF/TCAM,  and  the  capability  for  one  host  to  assume  control  of  an 
adjacent  host's  communications  controller  in  the  event  of  a  host  failure. 

Any  user  wishing  to  implement  a  fully-functional  SNA  network  must  consider 
implementing  either  ACF/VTAM,  Release  ^or  ACF/TCAM,  Version  2^"^ 
Release  l^r  later.  These  releases,  introduced  in  June  1981,  contain  the 
maximum  range  of  SNA  functions  currently  available.  For  example,  only 
these  releases  provide  for  multipl^DLC  links  operating  in  parallel  between 
adjacent  3705  or  3725  communications  controllers. 

These  multiple  links  can  be  arranged  logically  into  transmission  groups, 
each  of  which  provides  a  single  logical  path  between  controllers, 
essentially  allowing  transparent  redundant  connections  over  which  data 
may  flow. 

This  multiple  active  routing  feature  allows  the  transmitting 
communications  controller  to  select  among  active  links  on  a  given 


-  I6-(U-SNE-III)  PH  11/13/84 


path,  providing  backup  service  should  one  or  more  links  fail  to  become 
overcrowded. 

ACF/VTAM  Release  3  and  4  and  ACF/TCAM  Version  2,  Release  3  also 
introduced  the  concept  of  virtual  routing,  by  which  an  application  can  request, 
or  be  assigned,  one  o^  three  priorities  for  transmission. 

The  communications  controller  then  queues  incoming  messages  and 
releases  them  according  to  priority,  invoking  a  time-out  function  to 
assure  that  low-priority  messages  do  not  age  excessively. 

A  session's  explicit  route  across  the  network,  combined  with  its 
priority,  is  that  session's  virtual  route.  (A  session's  explicit  route  is  the 
path  of  its  messages  from  source  to  destination  over  transmission 
groups  between  intervening  communications  controllers.) 

More  than  one  virtual  route  may  share  a  single  explicit  route. 

Additic^^ly,  these  releases  of  the  ACF  access  methods  provide  for  multiple 
ownerships  of  a  single  communications  controller  by  up  to  eight  host 
processors,  and  the  attachment  of  more  than  one  communications  controller 
via  either  channels  or  SDLC  links. 


MULTISYSTEM  NETWORKING 

fit  5S<^?'» 

All  the  network  elements  defined  to  an  SSCP  comprise i+f  domain. 


V        An  addressable  unit  may  belong  to  only  one  domain,  even  if  more  than 
one  access  method  resides  in  its  host  (as  in  MVS  or  VM/370 
configurations). 

The  Multisystem  Networking  Facility  (MSNF)  makes  cross-domain 
communications  possible. 


-  17  -  (U-SNE-III)  PH  1 1/13/84 


0 


'The  MSNF  gives  the  access  method  the  ability  to  determine  the 
location  of  a  foreign  resource,  to  obtain  from  its  access  method  the 
necessary  "bind"  information  for  session  establishment,  and  then  to 
initiate  a  session  between  an  element  in  its  domain  and  the  foreign 
resource. 


The  SSCP  is  but  one  resource  of  the  access  method.  Other  logical  modules,^ 
^such  as  the  Message  Cental  Program  (MCP)  and  the  software  of  the 
communications  control  lep/work  together  to  provide  for  the  coordinated  and 
efficient  movement  of  message  traffic  into  and  out  of  the  host. 

3704,  3705,  AND  3725  COMMUNICATIONS  CONTROLLERS 

A  user  must  attach  at  least  one  local  3704,  3705,  or  3725  Communications 
Controller  before  any  SNA  terminal  devices  can  be  configured. 


r 


There  is  one  exception  to  using  a  370X  or  3725— the  433 1  processor  is 
capable  of  supporting  an  eight-line  Integrated  Communications  Adapter 
(ICA)  that  can  accommodate  SNA  communications. 


From  a  migration  point  of  view,  a  single  entry-level  3705-80  could  suffice  for 
beginning  an  SNA  system.  The  3705-80  can  support  a  single  channel 
connection  to  a  single  host,  and  up  to  16  communications  lines. 

A  fully^onfigured  3725  can  accommodate  up  to  256  full-duplex 
communications  lines,  and  connection  to  up  to  eight  host  processors  via 
channel  attachment  or  SDLC  communications  lines.  Thus,  the  3725  may  serve 
as  a  local  communications  controller  for  one  or  more  hosts,  while  serving  as  a 
remote  controller  for  others. 

IBM^^ovided  software  permits  three  different  modes  of  operation  for  the 
communications  controller,  which  provides  for  a  staged  migration  toward 
achieving  full  SNA  networking  functionality. 
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The  Emulation  Program/Virtual  System  (EP/VS)  and  the  Emulation  Program 
for  the  IBM  3725  (EP/3725),  when  loaded  in  a  370X.  or  3725.'^espectivelX 
causes  |<i  to  emulate  a  hard-wired  270X  device.      V  /» 

A  370X  or  3725  in  EP  mode  does  not  support  SNA,  and  cannot 
accommodate  the  attachment  of  any  SNA/SDLC  device. 

Neither  will  1^  relieve  the  host  of  the  communications  processing 
burden  if  incurred  with  a  270X  or  ICA. 

When  SNA  devices  are  introduced  to  a  system  with  a  communications 
controller  operating  in  EP  mode,  the  user  will  need  to  progress  to  the 
Partitioned  Emulation  Program  (PEP)  mode.  This  entails  adding  the  SNA 
Network  Control  Program/Virtual  System  (NCP/VS). 

The  front^nd  under  PEP  operates  in  both  EP  and  NCP  modes 
simultaneously,  as  shown  in  Exhibit  IM-I. 

The  PEP  mode  permits  its  BSC  and  async  communications  lines  to  be 
converted  to  NCP  control  for  EP  one  at  a  time.  Until  this  conversion 
is  complete,  however,  the  host  is  still  burdened  with  the  control  of  the 
devices  attached  to  the  EP  partition. 

<^  r 

When  all  device^have  been  defined  to/ and  brought  under  the  control  of  the 
NCP  partition,  the  EP  is  deleted,  leaving  a  communications  controller 
operating  in  NCP  mode  only.       SNA  system  is  now  in  effect,  as  shown  in 
Exhibit  III-2.  Ay\ 

NCP's  primary  function  is  to  handle  the  data  routing  and  transmission  tasks  of 
the  network.  It  interacts  with  the  controller's  communications  scanners  and 
line  adapters  on  one  side,  and  the  access  method  on  the  other. 
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In  addition  to  controlling  and  nnaintaininq  the  lines  and  tepninals  attached  to 
wwr communications,  such  as  polling,  addressing,  buffering,  error  recovery, 
code  translation,  character  assembly  and  disassembly,  speed  selectioi^nd  line 
management,  the  NCP  handles  message  switching  to  remote  communications 
controllers,  line  error  and  other  statistics,  and  performs  a  variety  of 
diagnostic  tests  and  tracing  functions  when  network  lines  malfunction. 

A  number  of  control  parameters  are  available,  and  require  specification  by 
the  user  when  the  NCP  is  generated. 


r 


These  include: 


Number  of  times  to  try,  and  amount  of  time  to  wait  for 
retransmission,  in  the  case  of  transmission  error. 

Alternate  paths  for  unrecoverable  error  transmission. 

Maximum  message  and  frame  size. 

Number  of  SDLC  frames  to  pass  before  requiring  validation. 

An^arameters  for  data  pacing  between  the  host  and  terminals. 

NCP  maintains  a  close  relationship  with  the  host^^c^ess  method,  and  receives 
all  the  messages  destined  for  a  host  application  whidn  pass  through  the 
communications  controller. 

The  NCP  jnsures  that  a  control  information  field  precedes  the  message, 
and  specifies  the  nature  of  the  message  and  its  destination  for  routing 
in  the  host. 


The  access  method  likewise  sends  control  information  and  commands  to 
the  communications  processor  to  request  that  the  NCP  perform  certain 
functions. 
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The  different  access  methods  permit  varying  degrees  of  support  for  the  NCP 
and  communications  controller  configurations. 


Exhibit  11 1-3  shows  which  host  access  methods  supporj^jtie^fferent 
modes  and  configuration*'of  the  370X  or  STZ^/TTshould  be  notedltiar^ 
only  TCAM  (or  ACF/TCAM)  will  support  either  the  EP  or  PEP  modes  of 
operation. 

NCP  or  NCP/VS  is  the  native  operating  mode  of  the  370X  in  an  SNA  system 
and  is  available  as  System  Control  Programming  in  a  single-system 
environment. 

The  native  operating  system  of  the  3725  is  ACF/NCP,  which  offers 
^  extended  networking  capabilities^BM  also  makes  available  an  ACF 
program  producTfor  the  370X,  ACF/NCP/VS. 

ACF/NCP/VS  and  ACF/NCP/3725  are  adjuncts  to  the  ACF  versions  of  TCAM 
and  VTAM. 

ACF/NCP  is  required  to  achieve  the  multisystem  networking  capability 
provided  by  ACF/TCAM  and  ACF/VTAM,  and  permits  networking  to 
other  hosts'  3705s  or  3725s  similarly  loaded  with  ACF/NCP. 


3725s  in  a  multisystem  environment. 

ACF/NCP  also  permits  servicing  two  or  more  local  hosts,  or  two  or 
more  access  methods  cohabiting  a  single,  partitioned  host,  as  shown  in 
Exhibits  III-4  and  III-5. 


The  IBM  X.25  NCP  Packet  Switching  interface  also  runs  as  a  software  module 
under  ACF/NCP. 


High-speed  (230. 


communications  using  SCLC  link  local  3705s  or 
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It  provides  an  interface  through  a  3705  or  3725  communications 
controller  between  an  SNA  network  end  an  X.25  packet  switching 
facility. 

The  interface,  announced  in  1981,  requires  a  special  Network  Interface 
Adapter  (NIA)  in  hardware  to  function. 


F.       HIERARCHICAL  AND  DISTRIBUTED  SYSTEMS 


SNA's  multisystem  networking  can  eliminate  the  need  for  redundant 
applications,  or  redundant  processors  performing  the  same  applications 
processing.^ 

4        Remote  terminals  seeking  access  to  the  same  application,  whether  in 
the  same  or  different  systems,  can  all  be  directed  under  SNA  to  a 
single  processor  in  which  the  application  resides  (as  illustrated  in 
Configuration  D). 

This  capability  illustrates  a  centralized,  or  hierarchical  approach  to  network 
configurations. 

SNA  can  likewise  support  a  decentralized,  or  distributed  configuration. 

In  such  a  system,  a  portion  of  application  processing  is  removed  from 
the  central  location  and  placed  at  the  location  where  work  is 
performed. 

While  the  centralized  approach  can  save  on  hardware  costs  through  the 
elimination  of  the  need  for  redundant  applications  processing,  the 
distributed  approach  can  save  considerably  on  costs  of  communications 
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facilities,  since  transmission  to  a  central  host  is  minimized^see 
Configuration 


Several  IBM  standalone  processors  can  be  readily  configured  in  an  SNA  system 
as  remote  distributed  subsystems.j^ 

if^     The  following  IBM  systems  arc  capa&Ic  oi.  perform'w^^aried  remote 

data  entry  functions^support  SDLC  communications  to  a  remote  hosty*^ 
widely  varying  degrees  of  processing  power,  applications 
functionality,  mass  storage.and  attachable  peripherals. 


System/34. 
System/38. 
Series/ 1 . 

8100  information  system. 
4331  processor. 


G.       NETWORK  MANAGEMENT 


o        Not  all  network  problems  and  contingencies  are  handled  automatically  by  SNA 
with  the  software  products  discussed  so  far.  For  this  reason,  IBM  markets 
separate  program  products  that  enhance  the  operation  and  network 
management  of  an  SNA  network.  The  IBM  user  needs  to  define  and  design  the 
entire  communications  network  completely  before  any  physical  devices  are 
installed.  The  number  of  variables  one  must  take  into  account  is  considerable 
and  includ^ alternate  routing  for  unrecoverable  error  transmissions,  time-out 
routines,  procedures  to  be  invoked  in  the  event  of  a  processor  failure,  and 
others. 
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The  capabilities  achievable  with  the  IBM  access  methods  and  NCP,  if 
properly  implemented,  are  extensive,  but  the  functions  these  products 
perform  relate  only  to  routine  communications  management. 


Users  must  provide  for  the  efficient  management  of  the  unex^i^ted, 
unusuaj^and  sometimes  disastrous  communications  problems  which  may 
arise.  ' 

No  matter  how  well  an  SNA  communications  system  is  planned  and  debugged, 
provisions  should  be  made  for  manual  operator  intervention  and  control  in  the 
event  of  unusual  network  problems.  \ 


7      ^  Two  network  management  program  products  run  on  either  VTAM  or 
TCAM  systems,  and  support  operator  control  capabilities. 

The  first  is  the  Network  Communications  Control  Facility  (NCCF). 

It  provides  immediate  operator  access  to  program  bases  and  services, 
access  methods,  and  operating  systems  so  that  changes  can  be  effected 
for  network  control  and  permits  the  establishment  of  changeable 
network  operator  stations,  a  customized  and  user-defined  list  of 
commands  to  support  backup  procedures,  and  other  functions  which 
support  operator  intervention  into  network  operation. 

The  other  announced  product.  Network  Problem  Determination  Application 
(NPDA),  operates  under  NCCF,  provides  extensive  error  tabulation  and 
recording,  and  automatically  assigns  probable  causes  to  the  errors  it  has 
recorded. 


also  permits  user-written  and.defined  operator  commands  and  exit 

I* 

routines  so  that  the  network  operator  can  screen  and  edit  message  and 
data  traffic. 
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The  latest  release  of  NPDA  runs  as  an  on-line,  interactive  program 
under  NCCF. 

An  additional  trouble-shooting  facility,  the  Network  Logical  Data  Manager 
(NLDM)  collects  and  displays  session-related  information  for  SNA  networks  to 
assist  in  problem  analysis.  NLDM  is  also  an  interactive  application. 

The  IBM  2725  Communications  Controller  features  a  Maintenance  and 
Operator  Subsystem  that  can  perform  loopback  modem  and  communications 
line  tests  when  used  with  suitable  IBM  modems. 


^A4lak^e^>me'the-'^^vave'o^  de  vek»prheiTt-tifKi 

V^r&Ui^X^^  y-^f.  Since  over  70%  of  the  available  market  currently  uses 
SNA,  companies  not  using  it  will  be  at  a  decided  disadvantage  in  terms  of 
future  network  interconnections  and  availability  of  large-scale  data  access.  So 


pronounced  is  this  effect/that/ most  other  companies  in  the  field  en^ 
specifically  designing  SNA  capabilities  into  their  products,  just  to  remain 
compatitive. 
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IV       CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 


An  understanding  of  SNA  and  packet  switching  is  important  because  high 
vendor  interest  is  forcing  development  in  that  direction.  It  is  still^^^he'SWave 
of  the  future." 

Users  need  to  develop  the  capability  to  fully  share  all  network  resources, 
including  lines,  remote  multiplexors,  concentrators,  terminals,  and  fron^tjend 
processors,  across  all  potential  users,  especially  in  a  high-demand^i^^oriented, 
time-variable  environment.  ^ 

Such  fjexibility  can  only  be  achieved  if  there  is  a  clear-cut  separation  of 
functional  responsibility  in  the  modules  that  control  the  network. 


r 


In  the  architectural  view  of  the  network,  different  functions  can  be 
clearly  associated  with  different  logic  modules  of  the  network. 


SNA  currently  occupies  more  than  70%  of  the  marketplace.  Thus,  it  will 
continue  to  exert  its  influence  over  the  rest  of  the  1980s,  and  well  into  the 
1990s. 

IBM  does  not  arbitrarily  change  protocols  unless  such  changes  are  dictated  by 
market  demands. 
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B.  RECOMAAENDATIONS 

o        Make  it  a  point  to  understand  SNA^its  use  and  i+s  linnitations.  Since  SNA  is 
very  dynamic  and  constantly  changing,  an  understanding  of  SNA  and  its 
options,  features,  and  interactions  could  save  a  considerable  sum  of  money  to 
users  who  are  committed  to  IBM  and  ii^^  software. 

P 

o        Anticipate  that  packet  switching  usage  will  continue  to  grow  ond^the  user 

base  will  expand  with  time^*|this  will  permit  easy  interface  with  various  users 
and  facilitate  data  transfer  over  long  distances. 

o        SNA  migration  is  tough.  But  remember^^NA  is  expected  to  expand  in  scope 
over  time  and  many  public  network  offerings  are  committed  to  it. 

o        The  primary  effect  on  the  user  will  be  easier  access  to  computer  power,  at 

significantly  teas  cost.  Thus,  SNA  is  a  very  cost/effective  solution  to  network 
problems.  -* 

o        When  migrating  to  SNA,  encourage  other  vendors  yotrao  business^ith  to 
provide  an  SNA  interface.  It  could  save  you  a  lot  of  frustration  and  money 
later  on,  especially  after  all  systems  are  firmly  established. 

o        CCITT's  X.25  protocol  and  OSI  software/hardware  layers  should  be  studied  in 
detail  and  used  whenever  applicable.  The  standardization  achieved  by 

^^ffeo* ^should  be  costj^fective. 

o        SNA  providoG  the  key  tool  lo  weate  a  corporate  data  utility,  allowing  the  user 
great  access  to  any  data  basej^^n  any  computer  on  the  network.  All  this  just 
b^  making^phone  call  into  the  system.       ^®  aware  of  the  security  A 
implications.  '  '^i^f*- 
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Multiple-opplication  communication  is  a  primary  goal  of  SNA  migration:  this 
will  increase  productivity,  costYeffective  sharing  of  computer  and 
communications  resources,  and  provide  better  backup  of  critical 
configurations. 


Y 

yor  li\ 


Recognize  that  SNA  has  its  problems.  Learn  to  either  avoid  them/or  live 
with  them. 


-  3  -  (U-SNE-IV)  PH  11/13/84 


1 


EXHIBIT  iI-1 


SYS^MS  NETWORK  ARCHITECTURE 
IS  A  POWERFUL  NETWORK  VEHICLE 


Subarea  Node  with  SSCP 
(Processor) 


SNA  Network-^ 


Subarea  Node 
Without  SSCP 
(Communication 
Controller) 


'  Peripheral  Node 
(Cluster  Controller) 


AP  Un. 

LU 

Map  a 

LU 

I  .- 

-I 
I 


PU 


I — 1 


Boundary  of  Path 
Control  Network 


I  j 


LU 


PU 


Peripheral 
Node 
(Cluster 
Controller) 


□ 


Peripheral  Node 
(Terminal) 


AP  = 

Attached  Processor 

LU  = 

Logical  Unit  (User) 

PU  = 

Physical  Unit 

SSCP  =  System  Services 

Control  Point 
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EXHIBIT  11-2 


SNA  DEFINES  A  COMPLETE  SPECTRUM  OF 
FUNCTIONS  AND  PROTOCOLS 


ACF 

Telecommunication 
Access  Methods 


VSE/POWER 

IMS/VS 

OS/DOS/VSE 

CICS/VS 

RJE 

DPPX/DTIVIS 

RES/JES1 

JES2 

JESS 

ACP/TPF 

TSO 

MVS/IDWS 
VM/VCNA 
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EXHIBIT  11-3 

SNA  IS  COMPATIBLE  WITH  X,25  PACKET- SWITCHING  NETWORKS 


User  Location 


DTE 


User 
Program 


Communications 
Access  Method 

I  —  —  —  —  —  —  —  —  —  —  ,  —  —  —  —  —  •»  —  ._ 


X.25 
Level  3, 
Packet 
Level 


X.25 
Level  2, 
Frame 
Level 


Communications 
Facility 


Public  Packet 
Switching  Network 


DCE 


Modem 


Modem 

Modem 

'-X.25  Level  1, 
Physical  Interface 


Modem 


I 

I  SNA  Domain 
I 


Network  Node 
Processor 


1  x.25 

1  1 

X.25 

I  Level  2, 

Level  3, 

1  Frame 

Packet  1 

1  Level 

Level 

X.25  Level  1, 
Physical  interface 


To 

Other 
Network  I 
Nodes 


EXHIBIT  ll-U 


OTHER  COMPANIES  ALSO  MANUFACTURE 
SNA/X.25  INTERFACES 


DEC  DNA 

Honeywell  DSA 

NCR  CNA 

Sperry.  DCA 

Data  General  DG/SNA 

Hewlett-Packard  DSN 

Prime  Primenet 
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EXHIBIT  11-5 


DEC'S  ETHERNET  IS  THE  LARGEST  COMPETITOR 


•  Features^ 

-  Branching  Tree  Topology 

-  Digital  Baseband  Transmission 

-  1000  Nodes  (Maximum) 

-  No  Limit  on  Number  of  Workstations 

-  10Mbps  Aggregate  Throughput 

-  0SMA/CD  Access  Method 

-  Packet;fSwitched  and  Broadcast  Address 
Methods 

-  RS-232C  and  Ethernet  Interfaces 


•  End-User  Applications^^ 

-  File  Transfer  and  Storage 

-  Message  Switching 

-  Protocol  Conversion 

-  Electronic  Mail 


•  Network  Interconnections 


-  External  Host 

-  X.25  Gateway 

-  LAN  of  Same  Type 

-  LAN  of  Different  Type 

-  SNA  Gateway 
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EXHIBIT  II-6 


DEC'S  GATEWAY  SYSTEM  OFFERS 
NON-IBM  COMPATIBILITY 


•  DEUNA  is  a  New  DEC  Communications 
Controller 

•  SNA  GATEWAY  Links  DEC  and  IBM 
Systems 

•  GATEWAY  Provides  Multiple 
Communications  Functions 

•  Inter-System  Communication  Can  Be  at 
Application  Levels 
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^^^^         EXHIBIT  11-7 


OSI  VERSUS  SNA  LAYERING  SCHEMES 


OSI  MODEL 


SNA 


"Application  Process" 

7  Application  Layer 

6  Presentation  Layer 

5     Session  Layer 

4    Transport  Layer 

3     Network  Layer 

^    Data  Link  Layer 
LAP  B  (HDLC) 

1      Physical  Layer 

End  User 


"Funnels" 
IMS,  CICS,  TSO,  JES 


"Access  Methods" 
VTAM,  TCAM 


Presentation  Services 


Transmission  and 
Data  Flow  Control 


Path  Control 

Data  Link  Layer 
(SDLC) 

Unnamed  RS-232C 
or  X.21 


Information 
Processing 
Section 


Information 

Integrity 

Section 


Communications 

Functions 

Section 


Communications  Facilities 
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EXHIBIT  11-8 


SNA  PROGRAM  RECOMMENDATIONS 


•  Networks 

-  ACF/TCAM 

-  ACF/VTAM 

-  ACF/VTAME 

-  ACF/NCP/VS 

•  Transaction  Processing 


-  DPPX/DTMS 

-  ACP/TPF 

•  RJE 

-  0S/VS1  —  RES/JES1 

-  OS/VSl—  JES/RJE 

-  0S/VS2  --  NJE/JES2 

-  0S/VS2  ~  JES3/RJE 

-  MVS/IDWS 

-  DOS/VSE/Power 

-  DPPX/RJE  Workstation 

-  OS/VS  —  JEP/FTP 

-  DOS/VSE  ~  JEP/FTP 

•  Host-Resident  Support 

-  SSP  —  ACF/NCP/VS 

-  DSX 

-  HCF 


/VS 


-  CICS/VS 
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EXHIBIT  ilI-1 


/ 

SINGLE  SYSTEiV^PARTITIONED  EMULATION  PROGRAM   (PEP)  MODE 


Application 


TCAM 


OS/VS 
Host 


SNA  capability  only  for  terminals  under  NCP  control. 
Terminals  under  EP  may  only  be  BSC  or  async.  Typical 
migration  configuration. 

Access  Method:    TCAM.     Only  TCAM  supports  PEP  mode. 

Operating  Systems;    Any  OS/VS. 

Communications  Controller:     3704,  3705,  or  3725. 
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EXHIBIT  Iil-2 


SINGLE  SYSTEM  j^NETWORK  CONTROL  (NCR)  MODE 


Applications 


TCAM  or  VTAM 


OS/VS  or 

DOS/VS 

Host 


NCR 


Complete  SNA  system.    Host  relieved  of  most  communications 
processing.    Terminals  supported  are  mixed  SDLC,  BSC/\ 
and  async. 

Access  Method;    VTAM  or  TCAM. 

Operating  System:    Any  OS/VS  or  DOS/VS. 

Communications  Controller:     3704,  3705,  or  3725. 
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EXHIBIT  III-3 
HOST  ACCESS  METHOD  SUPPORT 


Communications 
Access  Metliod 

Emulation 
Program 

EP/VS  or 
EP/3725 

Partitioned 
Emulation 
Program-PEP 

Network 
Control 
NCP/VS* 

Multisystem 
Networking 
ACF/NCP/VS  or 
ACF/NCP/3725 

Remote 
Communications 
Controllers 

TCAM,  Levels  8,  9 

Supported 

TCAM,  Level  10 

Supported 

Supported 

Supported 

ACF/TCAM,  All 

Supported 

Supported 

Supported 

Supported** 

Supported 

VTAM.  Level  2 

Supported 

Supported 

ACF/VTAM,  All 

Supported 

Supported  ** 

Supported 

Not  supported  on  the  IBM  3725. 

ACF/NCP/3725  is  supported  only  under  ACF/TCAM  Version  2  Release  4AACF/VTAM  Version  1  Release  3  (MVS  only,  with  appropriate 
PTF),and  ACF/VTAM  Version  2  (MVS,  VS1,  and  VSE). 


EXHIBIT  111-4 


MULTIPLE  HOSTS;  SINGLE  COMMUNICATIONS  CONTROLLER 


DOS/VS 
Host 


2740 


3270 


Applications 


ACF/VTAM 


Applications 


ACF/TCAM 


Local  3705  or 
3725  NCP 


OS/VS 
Host 


3790 


ACF/NCP/VS 

Sys/34 

81  00 

2780 


I 


Multisystem  configuration/  permits  any  remote  terminal /system  to 
access  any  application  in  either  host  automatically. 

Access  Method:    ACF/TCAM  or  ACF/VTAM  in  each  host. 

Operating  System:    Any  OS/VS  or  DOS/VS. 

Communications  Controller:     3705  or  3725;  requires  ACF/NCP/VS- 


©1984  by  INPUT.  Reproduction  Prohibited. 


INPUT 

USNE 


EXHIBIT  111-5 


MULTIPLE  HOSTS^  MULTIPLE  COMMUNICATIONS  CONTROLLERS 
Jo 


Applications 


ACF/TCAM 


ACF/NCP/VS 


3770 


OC/VS  2 

(MVS) 

Host 


Applications 


ACF/VTAM 


Local 
3705 
or  3725 


3270 


DOS/VS 
Host 


Applications 


ACF/NCP/VS 


Remote 
3705 
or  3725 


2740 


Sys/34 


ACF/TCAM 


ACF/NCP/VS 


Sys/38 


OS/VS  1 
Host 

Applications 

OS/VS  2 

(SVS) 

Host 

ACF/VTAM 

Local 
3705 
PX  3725 

ACF/NCP/VS 

Local 

3705 
or  3725 

2780 


Large-scale  SNA  system;  each  host  with  a  local  3705,  interconnected  via  high-speed  SDLC  links. 
Access  to  any  host  from  any  terminal/system. 

Access  Method:    ACF/VTAM  or  ACF/TCAM  in  each  host. 

Operating  Systems:    Any  OS/VS  or  DOS/VS  per  host. 

Communications  Controllers:     3705  or  3725;  each  with  ACFVNCP/VS. 


APPENDIX 

SNA:  Challenges  &  Opportunities 

Survey  Questionnaire 


Name  of  Company   

Do  you  have  or  will  you  have  extensive  in-house  private  networks? 


Do  you  use  or  require  packet  switching?   

Which  transmission  protocols  do  you  use  (or  are  planning  to  use)? 

SNA   

X.21   

X.25   

DECNET   

Other   

Do  you  know  which  protocol  layers  you  are  currently  working  with: 

Data  Link  Control   ? 

Path  Control   ? 

Transmission  Control  ? 
Data  Flow  Control  ? 

Presentation  (Code  and  Format)  Services  ? 
What  will  be  your  future  network  requirements? 
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